在前一篇的介紹中,我們已經可以把 Trace 紀錄下來並且傳送至 zipkin
,實際上後面的工具使用,建議還是使用目前已經一統可觀測宇宙的公開標準 OpenTelemetry
,這邊我就以目前也有支援 OpenTelemetry
的 Cloud Trace
做為儲存與查閱的目的地。
OpenTelemetry 在標準之外,也希望提供避免 vendor lock-in
的實現,所以 OpenTelemetry Collector
實現了 trace
、metrics
與 logs
的統一設定與豐富的社群支援(opentelemetry-collector-contrib
),可以方便且快速將工作流串起。
首先我們在 docker-compose.yaml
中新增一個 collector 的服務:
otel-collector:
image: otel/opentelemetry-collector-contrib
volumes:
- ./collector:/etc/otelcol-contrib #config.yaml
environment:
- GOOGLE_APPLICATION_CREDENTIALS=xxxxxxxxx
ports:
- 1888:1888 # pprof extension
- 13133:13133 # health_check extension
- 4317:4317 # OTLP gRPC receiver
- 4318:4318 # OTLP http receiver
collector
的 yaml
設定檔
# ./collector/config.yaml
receivers:
otlp:
protocols:
grpc:
http:
exporters:
logging:
verbosity: detailed
googlecloud:
log:
default_log_name: ltm-sample-app
googlemanagedprometheus:
processors:
resourcedetection:
detectors: [ env, gcp ]
timeout: 2s
override: false
batch:
extensions:
health_check:
pprof:
service:
extensions: [pprof, health_check]
telemetry:
logs:
level: "debug"
pipelines:
traces:
receivers: [otlp]
exporters: [logging, googlecloud]
processors: [batch]
metrics:
receivers: [otlp]
exporters: [logging, googlemanagedprometheus]
logs:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ logging, googlecloud ]
因為我先在本地測試,所以需要將 service account
的金鑰放入容器中使用。
然後將 OtlpHttpTransport
的目標 endpoint
改成 http://otel-collector:4318/v1/traces
$transport = (new OtlpHttpTransportFactory())
->create('http://otel-collector:4318/v1/traces', 'application/json');
然後重新發送 request 到 API endpoint。之後就可以在 Cloud Trace
的 UI 上查詢到剛才發送的 Trace
了。
不論是在 Cloud Run
或是在 k8s
上,最近都可以聽到了一個比較新的特性: sidecar
。
雖然 sidecar
會使用了額外的資源,但是使用上彈性且隔離在 application
之外,可以更加方便維運的調整。
所以 Cloud Run 雖然剛釋出了支援,但是可以先測試看看,這邊有很簡單的範例跟可行的佈署文件,在自己的專案中可以馬上測試且試用。
如果對於 Observability
與 OpenTelemetry
相關的深度理解
與實際於 production 環境落地
這個相關全家桶的一條龍工程師們,可以參考這邊的詳細介紹: 你以為你在學 Grafana 其實你建立了 Kubernetes 可觀測性宇宙